REMARKS 



The above amendment and these remarks are responsive to 
the non- final office action of Examiner Pham, mailed 6 Aug 
2004. 

Claims 1-15 are in the case, none as yet allowed. 

Drawings 

The Examiner objects to the informal drawings 
originally filed in this case. 

Applicants submitted formal drawings on 22 Jan 2002 , 
which were acknowledged as received by the Office on 11 Feb 
2002. A copy of this submission is appended hereto. 

For the convenience of the Examiner, a new set of 
formal drawings is submitted herewith. 

Applicants request that the requirement for formal 
drawings be reconsidered and withdrawn. 
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35 U.S.C. 112 



Claims 2 and 3 have been rejected under 35 U.S.C. 112, 
second paragraph, for the use of the phrases "implicit 
request' 7 and "explicit request", respectively. 

With respect to claim 2, an "implicit" request is one 
where it is assumed all clients want a confirmation record 
(as distinguished from an "explicit" request) . This is used 
in an environment where the server doesn't negotiate this 
and always returns a confirmation whether it was requested 
or not, and assumes the client ignores the confirmation 
record if it doesn't want it. Those of skill in the art 
will understand this meaning, for in the context of this 
invention, the alternative definitions suggested by the 
Examiner of "indirect request", "unquestionable request", 
and "unconditional request" would not be applicable. 

With respect to claim 3, an "explicit" request is one 
where the client specifically sends a negotiation request to 
the server saying it wants the confirmation record returned. 
This is used in environments where the server makes this 
negotiation optional and only sends the confirmation upon 
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request. Those of skill in the art will understand this 
meaning, for in the context of this invention, the 
alternative definitions suggested by the Examiner of 
"clearly stated request" would not be applicable. It could 
also be expressed as a "direct" request, as suggested by the 
Examiner. 

With this understanding, applicants request that the 
rejection of claims 2 and 3 under 35 U.S.C. 112 be 
reconsidered and withdrawn. 



35 U.S.C. 102 

Claims 1-3, 7, 12, and 14 have been rejected under 35 
U.S.C. 102(b) over U.S. Patent 5,931,913 (Meriwether). 

Applicants "confirmation record" is not really 
confirming anything, it is not "confirmation" in the sense 
that Meriwether is using it. Applicant's use of the term is 
merely the name of a piece of information the server returns 
to the client once the Telnet protocol negotiations are 
finished. This "confirmation record" simply contains 
descriptive information about the Telnet session itself. 
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On the other hand, Meriwether uses the term 
"confirmation" in the sense that the session connection was 
established - that the client was able to connect to the 
server so that it can start the Telnet protocol 
negotiations . 

Thus, Meriwether's description is not referring to 
"Telnet protocol communications" (in the context of 
"confirmation") but rather to "TCP/IP protocol 
communications" . 

With respect to Claims 1, 12, and 14, the Examiner 
refers to Meriwhether, Col. 7, lines 44-44, citing this for 
teaching "negotiating environment parameters for 
establishing a connection-oriented connection with the 
server. 

Applicant's claims 1, 12, and 14 are here referring to 
"environment parameters" which are Telnet protocol 
parameters. Meriwether is describing a general 
communications connection between a client and server, 
normally something supplied via sockets in the layer below 
Telnet, which creates a connection over which the Telnet 
protocol information can then be sent. This can be seen in 
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Col. 7, lines 50-55 where Meriwether states that after the 
"...confirmation of establishment of the channel..." that a 
"...Telnet dialog can then commence...". In other words, no 
Telnet environment parameter negotiation has yet begun when 
Meriwether's "confirmation" is issued, which is only an 
indication that a communications channel has been 
established (but no Telnet dialog has yet occurred.) 

Further with respect to Claims 1, 12, and 14, the 
Examiner refers to Meriwether, Col. 3, lines 46-49, citing 
this for establishing the communications channel. 

Again, applicant's use the phrase "confirmation record" 
in the sense described above, which is not the same sense as 
used by Meriwether. 

Claims 2, 3 and 7 depend from claim 1, and are 
similarly distinguished. 



35 U.S.C. 103 
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Claims 4-6, 8-11, 13 and 15 have been rejected under 35 
U.S.C. 103(a) over Meriwether in view of U.S. Patent 
6, 128, 662 (Bolton) . 

Regarding claim 4, the Examiner characterizes 
Meriwether as teaching operating a client to establish a 
network connection with a server providing a confirmation 
record but does not teach a device name assigned by the 
server to the client connection. The Examiner refers to 
Bolton at Col. 7, lines 50-56 for that teaching. 

Claims 4-6 depend from claim 1, and the above 
discussion of Meriwether is pertinent to these claims as 
well, and Bolton is not cited as pertinent to the critical, 
distinguishing point. That is, the "confirmation record" 
being claimed by applicants in a Telnet protocol negotiation 
is not the same as a "confirmation" that a session was 
established as is the case in TCP/IP and Meriwether. 
Applicants could just as well have referred to "device-name- 
actual ly- as signed- and- autosignon- success -or- failure -status 
record" instead of using the term "confirmation" record. 
Applicants claims are not directed to how to build up a 
virtual device name to be requested, but rather are 
communicating the actual device name that was used. A 
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client may or may not request a device by name, but the 
actual device name selected is not known, and the 
confirmation record in applicant's instance is how the 
server tells the client the actual device name. 

Further regarding claim 5, the Examiner refers to 
Fujiyama et al U.S. Patent 6,052,728 (Fugiyama) in the 
context of Official Notice that providing a log for a cause 
of a failed connection is well known. 

Applicants traverse. The "failed connection" being 
claimed by applicants is not the same as the different kinds 
of Telnet protocol failures. Applicants here claim Telnet 
protocol or applications failures such as an auto-login 
failure, or failure to obtain a particular Telnet device 
name. Fujiyama is clearly logging failure information as it 
pertains to communication connections between network 
computers (for example, TCP/IP connections, which are a 
different and lower communications layer below Telnet 
connections). Fujiyama does not use "confirmation records" 
as applicants do since these are Telnet negotiations, and 
therefore would not be able to "recover" from such a Telnet 
failure by automatically prompting the client to supply a 
different device name or login information. However, a 
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Telnet client implementing applicants invention would be 
able to do this recovery in addition to logging any such 
failure information for later analysis. 

Further regarding claim 6, the Examiner cites 
Meriwether Col. 8, lines 55-63 with respect to retrying the 
negotiating step. Applicants agree that Meriwether is 
similar in that negotiations may be retried. However, 
Meriwether does not teach retrying in response to a 
confirmation record result. As previously discussed, 
applicant's "confirmation record" is not one of the 
"confirmations" or negotiations done by Meriwether and 
therefore responding to a confirmation record by Meriwether 
is not the same as in applicant's claim. For example, there 
is no way for Meriwether to retry a failed login sequence, 
because the login sequence success or failure is unique to 
applicant's confirmation record. 

Regarding claims 8, 9, 13 and 15, the Examiner refers 
to Meriwether Col. 3, line 46-49 for teaching use of a 
confirmation record for establishing a communications 
channel, Col. 7 lines 54-62 for teaching a Telnet logon 
dialog with option negotiation, Col. 7, line 65 to Col. 8, 
line 4 for negotiating parameters, Col. 7, lines 47-52 for 
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providing to the client a confirmation record. Applicants 
traverse this characterization of Meriwether insofar as it 
is applied to these claims. The Meriwether confirmation 
record is not the confirmation record of applicants, which 
comes from applicant's "new- environ" parameter negotiation, 
which negotiation is not taught by Meriwether. 

The Examiner cites Bolton as teaching a virtual name 
generated by the server to the client during negotiation 
(Col. 7, lines 50-56). However, applicants are not 
constructing a device name as Bolton does, but rather simply 
returning the device name and failure status to the client 
so that the client can retry/recover based on the 
information. 

The Examiner takes "Official Notice" based on Fujiyama 
et al . , which discloses a log file for recording 
communication activity (Col 4, line 42 to Col 5, line 5.) 
Applicants traverse. Fujiyama is logging session connection 
information (TCP/IP layer information) and would not have 
access to Telnet protocol negotiation information. 
Therefore, Telnet protocol negotiation failures would not be 
seen by Fujiyama nor could these failures have any kind of 
recovery based on Fujiyama. 
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Claim 10 depends from claim 9. 

Regarding claim 11, applicants claim a new-environ 
negotiation which is a Telnet negotiation similar to 
terminal -type, binary, and end-of -record negotiation. This 
is new-environ negotiation is not taught by Meriwether, The 
claimed confirmation record information is communicated via 
the new-environ negotiation, which is not taught by 
Meriwether. The new-environ negotiation claimed is not 
similar to the confirmation of session establishment 
previously discussed with respect to Meriwther. 



SUMMARY AND CONCLUSION 



Applicants urge that the above amendments be entered 
and the case passed to issue with claims 1-15. 



The Application is believed to be in condition for 
allowance and such action by the Examiner is urged. Should 
differences remain, however, which do not place one/more of 
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the remaining claims in condition for allowance, the 
Examiner is requested to phone the undersigned at the number 
provided below for the purpose of providing constructive 
assistance and suggestions in accordance with M.P.E.P. 
Sections 707.02 (j) and 707.03 in order that allowable claims 
can be presented, thereby placing the Application in 
condition for allowance without further proceedings being 
necessary. 



Date: Monday, 8 Nov 2 004 

Shelley M Beckstrand, P.C. 
Attorney at Law 
61 Glenmont Road 
Woodlawn, VA 24381 

Phone: (276) 238-1972 

Fax: (276) 238-1545 
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Sincerely, 



R. G. Hartmann, et al . 



By 




